Designing for the Decision, Not the Display - How AI Products Earn Trust Under Uncertainty

Nyekachi Wihioka at UXDX Community: Trust at Scale: Designing AI Under Uncertainty and Team Risk. Video: https://youtu.be/mi2kmy0Hq_E

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

An argument about a usage screen

[00:00:08] Hi everyone. My name is Nyekachi and I'm the head of product design at RideScan, where I spend most of my time designing products for complex systems, which is probably why I keep finding myself in debates about data dashboards, and which is probably why our talk today is more like the foundation of it.

[00:00:42] We'll be talking about designing for the decision and not the display. But before we go deeply into that, I want to start off with an argument. We were designing a usage screen for our cloud platform. The screen shows users how the API calls are being used: which calls are being made, what activity's happening under each robot, how usage maps across the different missions. I had the wireframe. I had the low-fidelity design, and I also had a very clear point of view about what this screen needed to do. I wanted users to be able to see everything, all the three API call types, the activity under each mission across each robot, all at a single glance. No clicking, no navigating. You just land on the screen and immediately you understand what's happening.

[00:02:00] But on the other hand, the engineer disagreed completely. And to be honest, his position was logical. Because the data was complex, there were multiple layers to it, and the sensible approach from an engineering perspective was to let users navigate to what they were looking for. Just click into a section, drill down, find the specific thing they were literally looking for. He wasn't wrong about the data. The data was just complex, but he was solving a different problem than the one I was trying to solve.

[00:02:55] So I went back to one question that usually cuts through every layout debate, which is: what does someone actually do the moment they land on the screen? And the answer was almost always the same. Something had prompted you, definitely. Something has prompted you, something has prompted a question. It could be an unusual bill that popped up. It could be a mission run, and they wanted to know how much API usage they consumed. It could be something strange that just popped up. They came to that particular screen with a question already half formed. And the interface that they met at that point literally answered it, I'll say, at the glance, at the beginning.

[00:04:04] So for me, at this stage, the moment you make them navigate, you've already failed it. We went with my approach, and honestly, I can't remember exactly how the conversation went. But it wasn't the dramatic moment of one person trying to convince the other. It was just clear over time which direction was right. But that disagreement taught me something, and I've been thinking about it ever since, which is leading me to our next slide.

Who carries the uncertainty

[00:05:01] What I've come to understand since the argument is that it wasn't really about layout. It wasn't about navigation. It wasn't about scrolling and all. It was about uncertainty and who carries it. And my approach showed everything. My approach at that point was show everything. No matter what, you just show everything at a glance, but put the uncertainty on the design. We had to figure out in advance what the user's question was going to be. We had to also do the interpretive work so that they don't have to do it.

[00:05:53] And when the interface does the full work, when it absorbs the uncertainty, the user will act with confidence. Trust begins to build within them over time, and the system begins to earn credibility through every interaction. But his approach, on the other hand, which we can see, navigate to find what you need, put the uncertainty on the user. They had to, which is, they had to figure out which section held the answer to their question. They arrived not knowing where to look, and the interface obviously didn't even help them at that point.

[00:06:52] And when the user absorbs the uncertainty, you get the cognitive overload. You get operators who, I would say, over-trust or under-trust the system. You get workarounds, people building their own processes around the interface, because the interface isn't meeting them where they are at that point. That's why I said every AI product makes this choice, either by design or by default.

[00:07:34] And I'm pretty sure that there are so many of us, even in the last few months, who've had a similar version of this argument. It could be like, it could be your PM saying, "We need to show the user everything." It could be engineering saying, "Surface all the data. Give them the full picture." It could even be the stakeholders asking to add one more metric to the dashboard, which obviously was already full.

[00:08:18] So for me this is not an exotic problem. I would say it's the daily reality of product teams building anything with data, building anything with AI, with any kind of complex system underneath it. And yet most of us are trained to think about design as an information problem. How do we organize this clearly? How do we make this data readable? These are the questions that I would say matter, but for me they are downstream of the question that actually determines whether an interface works or not.

[00:09:15] The upstream question, the one we should be asking first, before we touch a single component, is: what decision is this particular individual or this user trying to make? And what is the minimum they need to make it confidently? Everything outside that is secondary. So by the end of this section, I want to give you guys three principles and three questions you can use immediately, before you open your Figma for your next project. Not the full process, just the starting point. Because if you get the starting point wrong, everything that follows after that is solving the wrong problem.

Design starts with the decision, not the data

[00:10:19] So the first principle we can see here is: design starts with the decision and not the data. It's what decision is this person trying to make? What is the minimum they need to make it confidently? Not what information do they need, not what data do we have, but what decision. Because a decision is specific. A decision has stakes. A decision has a time frame. The person needs to make it now, or before they can move on to the next thing. And once you know the decision, everything else just becomes a filter.

[00:11:27] Every piece of information on the screen should be answering that one question: does this help the person make the decision they came here to make? And if yes, it stays. If no, it's more like a candidate for removal, or at least for moving it completely out of the primary view. But the reality is that this sounds simple, but genuinely it's hard to do. Because there will always be more data available than the user needs. There's always someone who wants that data visible because it's available, not because it supports a decision.

[00:12:17] "But what if they want to see it?" is the question you would get. And my answer is always that want and need are two completely different things. Design for what they need to decide. Let them find the rest if they keep looking. So in my usage screen, the question I was anchoring to was this: does the usage this period look right? For me, that's the decision. Everything on the screen should exist in service of answering that question at a glance. Start with the decision, then work backwards to the data.

Showing more is not safer

[00:13:21] The next one: I want to also push back on something that usually comes up constantly in product conversations. The idea that showing more is safer than showing less. That if you surface all the data, all the options, all the information, you've covered yourself. The user has everything they need. Fine. Whatever happens next is on them. Yes, I clearly understand where this comes from. It feels responsible. It feels thorough. It feels like you've respected users' intelligence by giving them the full picture.

[00:14:19] But what actually happens? Every additional piece of information on screen is cognitive work a user has to do. They would have to look at it. They would have to assess whether it's relevant to what they are trying to do currently, and either act on it or dismiss it. That work is more, you know, for an individual element. But the thing now is it compounds over time.

[00:15:04] So the core decision data, for that one, you keep it. Supporting context, yes, you keep it. Secondary data, you review it. Nice to have, which we all know, beautiful UI, sometimes you remove it. Never used, remove it. And when you add complexity the user doesn't need, especially in a system where they're already operating under pressure, you are not just being thorough. You are transferring your uncertainty to them.

[00:15:50] So the most valuable thing a product designer can do for a complex system is deciding what not to show, you know. Not what to organize, not how to build the hierarchy, but what to remove entirely from the primary view. You know, honestly, that's a harder conversation to have than "let's make the layout cleaner," because removing things obviously makes people nervous. But it's the conversation that separates interfaces that feel simple from interfaces that are simple, where simplicity is the result of deep understanding of what users actually need and not the result of having less to show. So complexity is not a feature. It's uncertainty transferred to the user, and the user is the one who pays for it.

Interpretation is design work

[00:17:03] And then the last principle. So this is the one that took me the longest to actually understand clearly. There's a version of respect for the user that looks like this: give them all the information, trust them to just figure it out, don't be precious about what they see. And there is a different version of respect for the user that looks like this: do the hard work of, I would say, synthesis and interpretation on their behalf, so that when they arrive at the interface, they can focus their cognitive energy on the decision itself, rather than making sense of the raw information. For me, the first version feels more respectful. The second version actually is, but they're two different things.

[00:18:29] So here's what I mean. We can see the raw data, as we can see: call A was made 47 times, call B was made 312 times, and call C was made 1,204 times, distributed across 12 robots. This is accurate. It's complete. It's also nearly useless for decision-making. What would actually help the user is "usage is normal," which is the second box we're looking at. Usage is normal, projected spend on track, no action needed.

[00:19:31] The second box, I would say, requires the interface to do the interpretive work: to translate the raw data into meaningful data, to make the connection between what the system knows and what the user needs to understand. That interpretive work is design work. It's one of the most valuable things we can do. And most teams aren't doing it. To be honest, they are surfacing the system's uncertainty directly to the user and calling it transparency.

[00:20:15] That's why I would say it isn't transparency for me. It is abdication. The interface should absorb the uncertainty so that the user can act with confidence. That's how AI products earn trust: not by showing everything the system knows, but by doing enough interpretive work that the user doesn't have to. That's the job.

Three questions before you open Figma

[00:20:48] So I want to give you something very concrete to take out of this section. Three questions, asked in order, before you design any data-heavy screen, any AI interface, any usage view, any dashboard. Not after you've built the wireframe; before you actually open Figma.

[00:21:14] The first is: what decision? What is this person trying to decide, and how quickly must they decide it? This anchors everything. The decision determines what information belongs on a particular screen, and the time frame determines how much cognitive load the user can actually afford at that time. An operator making a real-time decision during an active mission has a completely different tolerance for complexity than a product manager doing a usual quarterly usage review. If you look at that: same data, different decision, different interface.

[00:22:21] The next will be: what context? What do they already know when they arrive? What prompted them to open that particular screen? This is the question most designers skip. They design as if the user is arriving cold, no prior knowledge, no mental model of what they are about to see. But the reality is that most users almost never arrive cold. Something definitely prompted them to open a particular screen. They have a question that was already half formed before they even opened that screen. So the interface that meets them at that stage, that anticipates the context they were arriving with, is far more useful than the one that starts from zero every time.

[00:23:31] And then the next will be: what does done look like? Is there a moment where the interface signals, you have what you need, you can act? If, for example, the user came to this screen with a question, there should actually be a moment when the interface has answered it. A moment where they can look at what they're seeing and think, "Okay, I understand. I can make this decision. I can move on." Does your interface take that moment, or does it just continue, showing data, displaying information, surfacing metrics, without ever giving the user the signal that they have what they need?

[00:24:36] It's more like you designing, I would say, designing the resolution. That moment of clarity is as important as designing the information architecture that gets them there. So, three questions. That's the whole framework in practice: what decision, what context, what does done look like. If you can answer all three clearly before you even start designing, then you are designing for the decision. And if you can't answer them, you are still designing for display.

Back to the engineer

[00:25:26] I want to come back to where I started from, the argument with the engineer. The thing I didn't see at the beginning: he wasn't wrong, to be honest. His instinct to let users navigate to what they needed, to not overwhelm them with everything at once, came from a good place. It came from respecting the complexity of the system and not wanting to force too much onto a single screen.

[00:26:10] But the difference between his approach and mine wasn't intelligence. It wasn't even experience. It was the question we were starting from. He started from: how do we organize this information well? But I started from: what decision is this person trying to make? Same system, same data, same user, but a different question, a different interface, a different experience.

[00:26:50] And here is what that disagreement showed me about AI products specifically. Every AI product you build is going to contain uncertainty. That's the truth. The system won't always be right, the data won't always be clean. The edge cases will always outnumber the happy path. The question is, I would say, the question is not whether uncertainty exists in your product. The question is who carries that uncertainty.

[00:27:27] You can either put the uncertainty on the user or on the design. Show them everything the system knows. Let them navigate. Let them interpret. Let them figure out what the data means under time pressure. Or you can put it on the design, so it can do the interpretive work. Build the interface that absorbs the uncertainty so that your users won't have to do the work. And then give them what they need to make that confident decision, and nothing else.

[00:28:16] One of those approaches builds trust at scale. The other asks users to trust a system that won't even help them understand it. Like I said, your users don't come to your interface to look at things. They came to actually decide something. So I would say design accordingly. Thank you. I don't know if there might be any questions.

Q&A

[00:28:54] Host: Thank you very much. That was a really nice recap. It's true. Design isn't about the UI. Design is about making sure that you can solve somebody's problems. I guess we just have time for one quick question. My question would be: I've heard that advice before, and it can be very subjective in terms of whether you're achieving it or not. What do you use to try to make it objective, that we are solving it and not just one person's opinion versus another?

[00:29:32] Nyekachi: That's exactly the tension. So, I would say, a lot of design debates, you know, sound very subjective because most times two smart people can look at the same interface and come to different conclusions. So the way I try to make it less subjective is by anchoring the conversation to the user's decision rather than design preference. For example, instead of asking, "Is this dashboard clear?" I would ask, "Can the user correctly determine whether their usage is abnormal within 30 seconds?" That's a measurable outcome.

[00:30:34] And that framework I shared, what decision, what context, what does done look like, is really an attempt to make design decisions testable. If we can clearly define the decision, then we can observe whether users can make that decision accurately, quickly, or confidently. But in practice, I would obviously look at things more like, I would say, time to decision, error rates, support tickets, whether the user needs to move down into multiple screens, and qualitative signals like their confidence.

[00:31:35] So if users keep saying, "Oh, I'm not sure what this means," or they're just creating spreadsheets outside the product, that's usually a sign that we've transferred uncertainty to them, instead of actually absorbing that uncertainty in the interface. Like you said, I don't think we completely eliminate uncertainty, but we can move the conversation from "Oh, I prefer this design" to "Which design helps users make the right decision with the least effort and highest confidence?" That's more, I would say, objective. It's more like an objective discussion.

[00:32:33] Host: Brilliant. So moving it away from opinions to real data.

[00:32:38] Nyekachi: Yes.

[00:32:39] Host: And that actually brings us to time. I just want to thank you once again for sharing, and I hope everyone out there enjoyed your talk as much as I did.

[00:32:48] Nyekachi: Yes, thank you. Thank you.